1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for a software program development tool. Still more particularly, the present invention provides a method and apparatus for generating internationalized versions of application programs.
2. Description of Related Art
Development of a commercial software application requires significant time and effort. Upon completion, most enterprises desire to generate the largest possible amount of sales for the application, and many enterprises attempt to sell their applications in foreign markets. In order to do so, each application must be adapted in several different manners for different markets, regions, or countries. For example, a US version of an application would require English menus and dollars for the default currency symbol, while a French version of the application would require French menus and euros for the default currency symbol. Many tasks must be completed in order to localize an application for a particular locale. Dates, times, numbers, and currency values must be displayed in the customary format for the locale. In addition, the application must be able to operate with the local character encoding standard.
Adapting applications for local markets could entail costly and time-consuming modifications to the applications if not performed methodically. To facilitate the task of creating multiple versions of an application for international markets, many commercially available software development tools and runtime environments have been developed with the recognition that applications would need to be adapted to different human languages and other requirements prior to being sold in different regions or countries. The term “internationalization” is used to describe the process of enabling a software application to be used in multiple international markets.
A properly internationalized application comprises functionality that enables it to be used in multiple international markets with only a minimal amount of localization effort. For example, an operating system can allow a user to select locale parameters. Assuming that an application has been created while adhering to certain internationalization guidelines of the particular operating system, the presentation of information by the application can be dynamically adapted to the user's selected locale during runtime.
While certain localization tasks can be rather simple, other localization tasks require significant effort by the application developer. For example, each human language string that might be displayed to a user during the execution of the application must be translated. Switching between languages can be facilitated by the operating system or some other configuration mechanism, but different sets of strings must have been generated and stored beforehand in order to be available to be retrieved at some later time based on a configuration parameter.
An application developer might use a translation program to expedite the task of translating the human language text strings, but both human translators and translation programs may not translate all of the strings correctly or intelligibly. To guard against translation errors, an application developer would generally incorporate translation verification procedures into the overall quality control and testing procedures that are applied to the application that is being developed.
Checking the appearance or correctness of certain application items, such as menus and help files, is rather straightforward, but verifying other items can be relatively difficult. In particular, each error or warning message that might appear during the operation of the application must be verified.
During translation verification testing, a pervasive problem entails operating the application that is being tested in such a manner to display each message so that it may be verified. It is especially difficult to force error messages to be displayed because it is often difficult to generate the operating conditions that would cause the application to display an error message.
Rather than embedding, i.e., hard-coding, human language text within the source code of an application, application text strings, including warning and error messages, are often congregated within certain types of files that are subsequently associated with the application in the runtime environment, such as resource files. Hence, the translated strings that are required to localize an application may be located within one or more files, and these files can be viewed and edited using a typical editor by a person who is verifying the translated strings. If an erroneously translated string were to be found within one of these files, then the person performing the verification could merely edit the string to correct the error. On the other hand, a typical application could comprise thousands of strings and messages, and human scanning of one or more large text files can itself be an error-prone process such that the person performing the verification could easily miss errors within the file. Hence, it would be advantageous to have a software tool for facilitating translation verification of strings and messages that are used by a localized version of an application.
More specifically, the Java™ language and runtime environment has been widely used in application development and execution because of the efficiencies that are gained via Java's “write-once, run-anywhere” approach, and Java™ facilitates the congregation of localization resources via special classes called “resource bundles”. By placing localizable elements within resource bundles, an application developer can separate user interface elements from locale-sensitive data, thereby simplifying the deployment of localized versions of applications.
Even though the localization of Java™ applications may have been simplified through the advent of resource bundles, the creation of localized versions of applications still requires some significant effort, and it may not be economically feasible to create localized versions for many languages and/or geographic regions, at least upon the initial release of an application. Moreover, a Java™ application may be easily transmitted or transported to a geographic region without being localized for the region. In other words, it is quite common to have a scenario in which a Java™ application is operated in a region in which it was not intended, particularly given the ease of disbursement of Java™ programs through the Internet and their execution on many different computing platforms.
Even if one has the desire to create a locale-sensitive version of a Java™ program, it may not be possible because the source files for the application may not be readily available. Java™ programs, especially applets, are commonly transmitted in the Java™ Archive (JAR) file format, which is a compressible, securable, file format that contains the bytecode class files and other files, e.g., image files, that are required to execute the program.
Therefore, it would be particularly advantageous to have a localization tool specifically for use in customizing Java™ JAR files.